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TITLE 

A System For Passing Algorithms With Polymorphic Parameter Sets 
In A Dependency Graph 
Of A Graphics Creation Process 

5 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention is directed to a system for evaluating 
dependancy graphs in a graphics creation environment more efficiently and, 
10 more particularly, to a system that passes not only data but also passes 
functions or algorithms between dependancy nodes. 
Description of the Related Art 

As graphics creation processes, such as the Maya™ system 
available from Alias jWavefront, Inc. a subsidiary of Silicon Graphics, Inc., 
15 typically used for animation and visual effects have gotten more 

complicated, designers have looked for ways in which to better control 
access to needed data and to better control the execution of the processes 
involved to improve execution speed or efficiency and resource utilization. 
One of the ways in which this has been accomplished is to control execution 
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through a mechanism, such as available in Maya™, called a dependency 
graph. A dependency graph (DG) and an associated node evaluation 
process as described by U.S. patents 5,808,625 and 5,929,864 
(incorporated by reference herein) provides a method for passing data 

5 through dependency nodes in a dependency graph. One of the drawbacks of 
this method is that the graph is a static object and can only be evaluated in a 
single state. The graph's state can be changed between evaluations through 
altering the mput values but at any evaluation step there is only one value 
available at each input attribute. 

10 Additionally, algorithms are hard coded into the dependency 

nodes, making it impossible to share the remainder of the code. Function 
calls also have fixed argument lists which are not sufficient for those 
writing replacement algorithms. Data streams requiring large amounts of 
evaluation are inefficient when going between dependency node 

15 connections. 

Because of these issues, one situation not well handled by 
this arrangement is the desire to evaluate a particular subgraph at many 
different combinations of inputs as rapidly as possible. Two problems 
arise; the possibility that the alteration of inputs will affect areas of the 

20 graph we do not wish to reevaluate, and the fact that traversing the graph to 
perform evaluations can be mherently more costly (time consuming) than 
simply evaluating the algorithms themselves. 

The usual solution to these problems is to create many 
different nodes, one for each variation required. 

25 The remedy for these problems, that is, what is needed is to 

allow not only data but also algorithms to be passed through the DG. Then, 
when a particular attribute is evaluated, the result is not the smgle value of 
that attribute with the current state of inputs, but instead an algorithm that 



-3 - 15-4-0995.00/1252.1051 

can be used to evaluate the attribute at any desired combinations of inputs 
(graph states). 



SUMMARY OF THE INVENTION 
It is an object of the present invention to allow algorithms or 
5 functions to be passed between nodes in a graphics creation process 
dependency graph. 

It is an additional object of the present invention to provide 
an evaluation process for a dependency graph that evaluates function input 
attributes. 

10 It is another object of the present invention to allow the 

mapping of parameters, both input and output, into and out of the functions 

that are passed. 

It is also an object of the present invention to allow the 

mapping of related but distinct data types. 
15 It is a further object of the present invention to allow 

incompatible functions to drive each other. 

It is an object the present invention to make a function of a 

source node an attribute of that node so that it can be passed to one or more 

destination nodes. 

20 It is an object of the present invention to allow sparse 

defmition of parameters in function calls through use of default values 
within the parameter mappings. 

The above objects can be attained by a system that passes 
algorithms between nodes of a dependency graph in a graphic creation 

25 process system. The destination node receiving the algorithm executes the 
received algorithm along with it's own algorithm avoiding the necessity of 
traversmg the graph multiple times when a data series is executed. The 
system also provides a mapping that allows parameters of the function to be 
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sparsely reordered to match the source and destination ftinction 
requkements. The algorithm can be passed using a pointer or by passing a 
self-evaluating data structure. 

These together with other objects and advantages which will 
be subsequently apparent, reside in the details of construction and operation 
as more fully hereinafter described and claimed, reference being had to the 
accompanying drawings forming a part hereof, wherein like numerals refer 
to like parts throughout. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows data passing between nodes of a dependency 

graph. 

Figure 2 shows function passing between nodes of a 
dependency graph. 

Figure 3 depicts hardware of the present invention. 

Figure 4 illustrates a dependency node graph. 

Figure 5 shows a connection between compatible function 
attributes fA on node A and fB on node B. 

Figure 6 depicts parameter mapping. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
The present invention is directed to a system for flowing 
algorithms through a dependency graph (DG) where data passing is replaced 
by passing the algorithm that generated the data. 

In a typical dependency graph evaluation, a function of a 
source node 2 (see figure 1), such as f(a)=b is called or evaluated as part of 
the evaluation of the node where a is the input data to the node 2 and b is 
the output data from the node 2. The output data is passed to a destination 
node, such as node 4, where the fimction for that node 4 (g(b)=c) is called 
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or executed. Each time the uiput data changes, this two node evaluation 
process must be performed again. In the present invention, in contrast, the 
function itself is passed along with the data from source node 6 (see figure 
2) to destination node 8 so that essentially g(f(d))=h is executed. As a 

5 result, if the input data "d" changes, or is a data series, the function can be 
evaluated without bemg burdened with the overhead of traversing the two 
nodes multiple thnes. Instead of traversing the node 6 to get data value e 
node 8 just calls the function f(d) = e, that has been passed followed by 
calling the function g(e)=h. 

10 The implementation of the present invention uses the DG 

evaluation algorithms discussed in the patents mentioned previously and 
found in the Maya™ system also previously mentioned with the addition of a 
single data type which is a self-evaluating structure used to evaluate sections 
of a graph at any combination of inputs. The self-evaluating structure will 

15 be described below using pseudocode in an evolutionary manner; starting 
with a very basic embodiment of the structure that handles the simplest 
requirements and finishing with the an embodiment that handles desired 
functions of the invention. 

The present invention is typically included in a system, such 

20 as depicted m figure 1, where a computer 12, such as a a Pentium III 
running Windows NT, is executmg a graphics creation system, such as 
Maya^"^, as controlled by a user operating input devices such as a keyboard 
14 and a mouse 16 or stylus, etc. The created graphic is displayed on a 
display 18 and the user is allowed to make modifications to the graphic. 

25 These modifications, as well as the original creation, are implemented 

through an evaluation controlled by the dependency graph where the present 
invention improves the speed of the evaluation by passing algorithms of the 
graph nodes. 
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A dependency graph, such as illustrated in figure 4, can 
typically include "input" nodes such as node 22 which mcludes an input 
such as a curve and node 24 which includes a time parameter input. Also 
typically included are output nodes, such as node 26 which mcludes the 

5 surface created by processing with the DG. Intermediate nodes, such as 
function node 28 and operation nodes 30 and 32 control operation on the 
inputs to produce the output. Nodes such as the revolve operation node 30 
include an algorithm that performs the desired operation, such as an 
algorithm that revolves an mput around an axis, and which, in accordance 

10 with the present invention, can be passed to a downstream node, such as 
node 32, for actual evaluation. 

Passing Simple Functions 

The simplest type of algorithm that can evaluate itself is a 
strongly typed function. A strongly typed function is one with a defined set 
15 and type of inputs, and a defined set and type of outputs. Since the types 

are all well defined this kind of structure can be implemented using a simple 
function pomter. 

The code class CfunctionDD set forth below illustrates a 
strongly typed data structure that can be used to contain a function f(x) = y , 
20 where x is a double value and y is a double value. 

Strongly Typed Self-Evaluating Data Structure 

class CfunctionDD : public Cfunction { 

CfunctionDD( (double)(*)(double) f) : fFunction(f) {} 
void evaluateO { fOutput = (*fFunction)(flnput); } 
25 void setInput(double I) { finput = I; } 

double getOutputO { return fOutput; } 
double flnput; 
double fOutput; 
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(double)(*)(double) fFunction; 

} 

The evaluation process is the same as in the DG evaluation process of the 
patents previously uncovered plus the addition of function evaluation once 
the function data has been retrieved from the DG attribute. 



Generalizing the types 

The mvention extends the idea of evaluating functions 
through data structures in several ways. The first of these ways is to make 
the types required by the function data structures more flexible in order to 
generalize the allowable connections within the dependency graph. For 
example, change a function parameter from "double" to "number" so that a 
fimction f(a)=b where a and b must both be double types, as in the example 
above, can match a function g(x) = y, where x and y are integer types. 
The evaluate process for function data set forth below helps accomplish 
this. 

Dependency Graph Evaluation Process For Function Data 



Evaluate(OutAttr) 
{ 

if( outAttr is not readable ) 
quit 

} 

For each input required to compute outAttr 
If( input attribute is connected ) 

Evaluate input attribute connection and save 
Else if( input attribute has no saved value ) 

Save default attribute value 
If( input attribute is a function type ) 
For each input parameter 

SetValue( inputParameter ); 
Evaluate input attribute 



-8- 



15-4-0995.00/1252.1051 



Save function evaluation result 
Compute the outAttr using saved values 
Return the value to the calling routine 

} 

5 To generalize the types, a method of run-time type identification (RTTI - a 
conventional method by which you tag data types and their inheritance 
relationships for the purposes of identifying an unknown piece of data) can 
also be included, so that function parameter types can be identified 
dynamically as the program executes. The data structure itself can then 

10 contain the information necessary to describe the set of input and output 
parameters the function accepts. The simple function from the previous 
example becomes the more complex data structure below. 



Generalized Self-Evaluating Functional Data Structure 



15 



20 



25 



Class CfunctionType 
TrttildArray 
TrttildArray 
TvoidPtrArray 
TvoidPtr Array 
Void 
Void 

outputValue 

TvoidPtrArray 
TvoidPtrArray 
Void* 

}; 



{ 

flnputTypes; 

fOutputTypes; 
fInputDefaults; 
fOutputDefaults; 

evaluateO = 0; 

setlnput( index, newValue ) 
{ flnputValues[index] = newValue; } 

getOutput( index ) 
{ return fOutputValues[index]; } 
flnputValues; 
fOutputValues; 
fFunctionPointer; 



30 



The instantiated data values for the function F(X)=Y are illustrated below. 
RTTIdouble is an identifier indicating the parameter m the corresponding 
position is of type double. 
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F(X)=Y Implemented Via The Self-Evaluating Functional Data Structure 



flnputTypes = [RTTIdouble]; 
fOutputTypes = [RTTIdouble]; 
flnputDefaults = [0.0]; 
fOutputDefaults = [0.0]; 
fInputValues = [X]; 
fOutputValues = [Y]; 
fPunctionPointer = &F; 
Void evaluateO = 

{ fOutputValues[0] = (*fFunctionPointer)(flnputValues[0]); } 

This extra description information is to be used to determine 
if function attribute types within the DG are compatible. This mvolves 
verifying that input and output types of the functions at the source and 
destmation attributes are the same. Then the function attribute fB (see 
figure 5) at the destination end node 42 of the connection can evaluate itself 
without any knowledge of the function f A at the other end or source node 
44, which is a requirement for proper DG operation. 

This added mformation introduces the possibility of 
incomplete input function settings (ie. by not specifically setting all values 
in the fInputValues array). To take advantage of this, default values for all 
mput parameters are added to the data structure. By omittmg calls to set 
certain input or output parameters their defaults will be used when the 
function is evaluated. In the context of the dependency graph (DG) this 
means that the source function need not be absolutely identical to the 
destmation function, only that its mputs and ou^uts be a superset of those 
at the destination. A function that defines a surface, /fM,vj = (x,y,z) can for 
example be used as a source to a simple curve fimction g(a) = b, assuming 
all values are doubles. 

The undefined second parameter v on function /will take on 
its default value while the first parameter u is set to g's parameter a. The 
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ouq)ut b of g will get it's value from the &st output off, namely x, and the 
second and third outputs, y and z. of/will be ignored. The data structure 
that defines the self-evaluating function passed through the connection looks 
as follows. 

5 Data Structure For Source Function F(U, V) = (X, Y,Z) 

fInputTypes = [RTTIdouble, RTTIdouble]; 

fOutputTYpes = [RTTIdouble, RTTIdouble, RTTIdouble]; 

fInputDefaults = [0.0, 0.0]; 

fOutputDefaults = [0.0, 0.0, 0.0]; 
10 flnputValues = [U, V]; 

fOutputValues = [X, Y, Z]; 

fFunctionPointer = &F; 

void evaluateO = 

{ [fOutputValues[0], fOutputValues[l], fOutputValues [2]] = 
15 (*fFunctionPointer)([fInputValues[0], flnputValues [1]]);} 

Note that due to the presence of defauh input values the fact that the node B 
will treat the function /as though it only had one mput and one output is 
unimportant. Only the compatibility of existing parameters is important. 

Mapping Parameters 

20 The limitation that parameters of the source function be a 

superset of the parameters of the destination function can also be removed. 
To accomplish this a pair of mappmgs are introduced. Thek function is to 
allow reassignment of input and output parameters by using an index, such 
as the list (2,3) which will assign input parameter 1 to function parameter 2 

25 and input parameter 2 to function parameter 3 . Such a simple numeric pair 
arrangement can be visualized via a mapping table as depicted in figure 4 
which allows mapping between source (input) and destination (function) 
parameters. Figure 4 shows the example discussed above where actual 
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input 1 is mapped to function input 2 and also shows actual input 4 mapped 
to function input L Such an arrangement creates a mapping between what 
is set on the destination function and what will internally be set on the 
source function, and vice-versa for output parameters. Shown below is the 
data structure with additions to implement such a mapping. 

Data Structure With Mapping Added 



Class Cmapphig { 

TindexArray flndexMapping ; 

Index getMapping(index) { return flndexMapping [index]; } 

10 }; 

Class CfunctionType { 
Public: 

TrttildArray fInputTypes, fOutputTypes; 
TvoidPtrArray fInputDefaults, fOutputDefaults; 
15 Cmapping flnputMapping, fOutputMapping; 

Void evaluateO = 0; 

Void setlnput( index, newValue ) 

{ fInputValues[index] = newValue; } 
outputValue getOutput( index ) 
20 { return fOutputValues[index]; } 

Private: 

TvoidPtrArray InputValues, fOutputValues; 
Void* fFunctionPointer; 

}; 

25 This mapping arrangement can allow arbitrary parameter 

reassignment, and with the existence of default parameter values for both 
mputs and outputs, the functions at the source and destination can be any 
arbitrary functions. Of course they will only be useful if at least one of 
each type of parameter is successfully mapped. If no outputs are mapped 

30 then the function will only ever return default output values. If no inputs 

are mapped then the function will only ever evaluate with default inputs and 
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so will probably be static. 

The parameter mapping between existing parameters is the 
obvious one. The input mapping (3,2) for example defines that setting 
input parameter 2 results in the internal input parameter 2 receiving the 
5 value, and that setting input parameter 1 results in the internal input 

parameter 3 receiving the value. Additional mapping modes can be used 
which defme a relationship where input parameters are ignored and output 
parameters are unmapped and will only take on default values. These 
modes are simply implemented using a flag such as a negative number 
10 mapping like (1,-1) where the second parameter passed is ignored. 

A mapping between the fmctions /(surface, u,v) = 
(color,x,y,z) and g(a) =b can easily be defined to take advantage of the 
compatible data types in a,b,u,v,xj,z as hypothetically shown below. 

Mappings On G To Accept Function F As Input 

15 flnputMapping = [1]; // Input "a" goes to F input "u" 

fOutputMapping = [1]; // Output "b" comes from F output "x" 

Generalized Mapping 

More complicated mapping functions than a simple numeric 
correspondence can be set up to map otherwise incompatible parameter 

20 lists. For instance, a function can be set up to transfer from one data type 
to another as well as reordering the position (e.g. Surface to Curve) so even 
completely different functions can drive each other through the use of 
reordermg and recastmg of parameters. This requires generalizing not only 
the mapping class but also the function class that makes use of it. In the 

25 following implementation the value and type are passed in for mapping but 
any other information that a mapping could make use of could also be 
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passed, e.g. the entire function data structure plus the value index. 



Revamped Function Data Structure Using Generalized Mapping Technique 



Class CfimctionType { 
Public: 

5 Trttild Array flnputTypes , fOutputTypes ; 

TvoidPtr Array flnputDef aults , fOutputDefaults ; 

Cmapping fInputMap, fDutputMap; 

Void evaluateO = 0; 

Void setlnput( i, newValue ) 

10 { flnputValues[i]=flnputMap.map(i, newValue, flnputTypes); } 

rttiData getOutput ( i ) 

{ return fOutputMap.map(i, fOutputValues[i], fOutputTypes); } 

Private: 

TvoidPtrArray flnputValues, fOutputValues; 
1 5 Void* fFunctionPointer ; } ; 

A typical mapping class is one that contauis both an index 
remapping as above plus a matrix of data casting methods which will 
change one type of data into another. A data casting method is a function 
that receives one type of data as input and returns a different type, the 
20 "cast" type, of data is output without, inasmuch is possible, changing the 
value of the data. For example, this trivial function "integerCast" makes 
use of a conventional compiler casting facility to cast from an integer type 
into a double type: 



double integerCast(int i) { return (double) i; } 



25 The implementation below has information on converting between double 

and integer values but the extension to other function types would be within 
the skill of those in the art. 
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Generalized Mapping Class That Converts Between Double And Integer 
Data Types, As Well As Reordering Parameter List 

Class Cmapping { 

Tindex Array flndexMapping ; 

5 rttiData map(index, srcData, typeArray) 

{ 

newlndex = flndexMapping [index]; 
dstType = typeArray [newlndex]; 

// Simple case : Requested type is the input data type 
10 if( srcData type = = dstType ) 

return srcData; 

if( srcData type is double && dstType is integer ) 

{ 

return RTTIint( srcData ); 

15 } 

else if( srcData type is integer && dstType is double ) 

{ 

return RTTIdouble( srcData ); 

} 

20 else 

Throw a type mismatch exception 

}; 

Within the DG context it is advantageous to describe several 
heuristics with which to perform automatic parameter remapping, so that 
25 compatible functions can be connected directly with minimal effort. The 

particular ones employed in this invention given two hypothetical functions 
/and g to be connected are: 

Match by position - If the parameter in position N of function 
/has the same type as the parameter in position N of function 
30 g then map them directly to each other. 

Match by name - In the DG all function parameters will have 
a name so this fact can be used to scan the parameters 
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remaining unmapped under the above heuristic and creating a 
mapping between any parameter in /that have the same name 
and compatible type as a parameter in g. 
Match by type - If the parameter in position N of function/ 
5 failed to map given the above rules then search all unmapped 

parameters of function g until one of identical type is found 
and map one to the other. 

Match by compatibility - Even if types are not identical a 
type-based matching is still possible if their exists a data 

10 castmg method as described above to convert the source 

parameter type of g into the destination parameter type of/ 
Match manually - Finally the user is provided access to the 
mapping index directly and can manually hookup parameters 
from /to parameters of g. The system verifies each mapping 

15 to ensure that the parameter types are compatible according 

to the rules above. 

A more sophisticated mapping technique that does not just 
perform 1 to 1 index mappings but N to N mapping can also be used. One 
of these mapping, for the function f(x,y,z) = s takes input 1 ("x") and puts 

20 it into inputs 1, 2, and 3, effectively turning this function into f(x,x,x). For 
the function f(vector), where "vector" is a combination of 3 double values 
another mapping sets a single part of it by mapping input 1 onto vector-sub- 
X, input 2 onto vector-sub-y, and input 3 onto vector-sub-z. This kind of 
mapping requires internal knowledge of the "topology" of the parameter 

25 lists so that it can decide which pieces of each parameter were mappable. 

The present invention can also provide for vectorization of 
the function calls. This involves setting a list of parameter values and 
having the self-evaluating data structure call itself once per set of 
parameters. For example, instead of calling f(x) = y where x and y are 
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doubles you'd call f(xArray) = yArray, where xArray and yArray are lists 
of doubles of arbitrary length. 

The present invention can also include an embodiment in 
which brand new self-evaluating classes are created for every function. 

5 This allows more specific mappings, tailored to the specific needs of the 
function, and avoids the small but potentially noticeable overhead of 
carrying around the function pointer. This embodiment, while potentially 
much faster, also uicludes the cost of creating and maintaming this 
embodiment which may be high. 

10 As can be seen from the above description an important 

feature of the present invention is the fact that the destination node has an 
idea of what its function is to perform via a certain algorithm. The 
destination node calls the self-evaluatmg data structure passed from the 
source node as though it precisely implemented that function, but in reality 

15 the data structure itself may contain an entirely different function with 

completely different parameters, both mputs and outputs. The power of this 
data structure really lies in this fact; that arbitrary functions can masquerade 
as other functions and do what is essentially "the right thing" or the actually 
needed thing from a programming standpoint. 

20 The many features and advantages of the invention are 

apparent from the detailed specification and, thus, it is intended by the 
appended claims to cover all such features and advantages of the invention 
which fall within the true spirit and scope of the invention. Further, since 
numerous modifications and changes will readily occur to those skilled in 

25 the art, it is not desired to limit the invention to the exact construction and 
operation illustrated and described, and accordmgly all suitable 
modifications and equivalents may be resorted to, falling within the scope 
of the invention. 
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What is claimed is: 

1 . A method of evaluating a dependency graph of a graphics 
creation process, comprising: 

passing a function of a first dependency node to a second 
5 dependency node; and 

evaluating the function as part of an evaluation of the second 
dependency node. 

2. A method as recited in claim 1, wherein the function 
comprises a self evaluating data structure. 

10 3. A method as recited in claim 2, wherein the function 

comprises a function having a defined set and type of inputs and outputs. 

4. A method as recited in claim 2, wherein the structure 
comprises a function pointer. 

5. A method as recited in claim 2, wherein the structure 
1 5 comprises a function calling method. 

6. A method as recited in claim 2, wherein the evaluating 
comprises determining a type of a passed parameter. 

7. A method as recited in claim 6, wherein the function 
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parameter types are identified dynamically as the dependency graph is 
executed. 

8. A method as recited in claim 7, wherein the data structure 
contains information describing a set of input and output parameters the 

5 function accepts. 

9. A method as recited in claim 8, wherein the information 
determines if function attribute types within the dependency graph are 
compatible. 

10. A method as recited in claim 9, wherein the data 
10 structure comprises default values for all input and output parameters. 

11. A method as recited in claim 1, further comprising 
mapping parameters of first and second functions of the first and second 
nodes. 

12. A method as recited in claim 11, wherein said mapping 
15 comprises using an index. 

13. A method as recited in claim 11, wherein the mapping 
defines a relationship where input parameters are ignored and output 
parameters are unmapped and take on default values. 

14. A method as recited in claim 11, wherein parameter 
20 value and type are passed for the mapping, 

15. A method as recited m claim 11, wherein the function 
data structure and value index are passed for the mapping. 

16. A method as recited in claim 11, wherein the mapping 
comprises an index remapping and a matrix of data casting methods which 

25 will change one type of data into another. 

17. A method of evaluating a dependency graph of a graphics 
creation process, comprising: 

passing a function of a first dependency node to a second 
dependency node, the function comprising a self evaluating data structure 
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comprising a function calling method and containing information describing 
a set of input and output parameters the function accepts where the 
information determines if function attribute types within the dependency 
graph are compatible and comprising default values for all input and output 
5 parameters; 

mapping parameters of first and second functions of the first 
and second nodes, where the mapping comprises an index, defines a 
relationship where input parameters are ignored and output parameters are 
unmapped and take on defauU values, where parameter value and type are 

10 passed for the mapping and the function data structure and value index are 
passed for the mapping; and 

evaluating the function as part of an evaluation of the second 
dependency node comprising determining a type of a passed parameter 
where parameter types are identified dynamically as the dependency graph 

15 is executed. 

18. A method as recited in claim 17, wherein the mapping 
comprises an index remapping and a matrix of data casting methods which 
will change one type of data into another. 

19. A method comprising: 

20 passing a function from a first node in a node network to a 

second node in the node network; and 

evaluating the function as part of an evaluation of the second 

node. 

20. An apparatus comprising a computer including a 

25 dependency node evaluation system having functions passed between nodes 
of a dependency graph of a graphics creating process. 

21. A data structure provided on computer readable storage 
controlling a computer in association with evaluating a dependency graph of 
a graphics creation process, the data structure comprising an RTTI 
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parameter list, a mapping substructure comprising an index mapping, 
mapping methods, and a data casting matrix, a function pointer, and 
methods for settmg inputs, getting outputs, and evaluating a passed 
function. 

5 22. A method of evaluating a dependency graph of a graphics 

creation process, comprising performing, by a destination node, of an 
algorithm having a function known to the destmation node by evaluating a 
self evaluating data structure passed from a source node and expected to 
precisely implement the function known to the destination node where the 
10 self evaluatmg data structure can comprise a different function with 
different parameters and performing the different function actually 
requested by the destination node. 
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TITLE 

A System For Passing Algorithms With Polymorphic Parameter Sets 
In A Dependency Graph 
Of A Graphics Creation Process 
5 ABSTRACT OF THE DISCLOSURE 

A system that passes algorithms or functions between 
dependency nodes of a dependency graph in a graphic creation process 
system using a pointer or by passing a self-evaluating data structure. An 
evaluation process associated with the graph includes an ability to 

10 distinguish between passed parameters based on type where one of the types 
allowed is a function type and types are identified dynamically as the 
dependency graph is executed. The node receiving the algorithm executes 
the received algorithm along with it's own algorithm avoiding the necessity 
of traversing the graph multiple times when a data series is executed. The 

15 system also provides a mapping that allows parameters of the function to be 
reordered to match the source and destination function requirements. 
Default values allow evaluation even when less than all parameters 
associated with the function are passed. Mapping flags allow passed 
parameters to be ignored. 
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My residence, post office address and citizenship are as stated below next to my name. 

I believe that I am the original, first and sole inventor (if only one name is listed below) or an original, first and joint inventor (if plural names are listed 
below) of the subject matter which is claimed and for which a patent is sought on the invention entitled: 

4./gvstgm for nboaing pohiminrrihir nl^ ^^^^^niii 11 1 flT""^" — ^ n^'inh nf i o raphirg rpntinn f — - ^ ^ ; 

the specification of which is attached hereto, unless the following box is checked: 

□ was filed on as United States Application Number or PCT International Application Number and was 

amended on (if applicable). 

I hereby state that I have reviewed and understand the contents of the above-identified specification, includmg the claims, as amended by any amendment 
referred to above. 

I acknowledge the duty to disclose information which is material to patentability as defined in 37 CFR § 1.56. 

I hereby claim foreign priority benefit(s) under 35 U.S.C. § 119(a)-(d) or § 365(b) of any foreign application(s) for patent or inventor's certificate listed 
below and have also identified below any foreign application(s) for patent or inventor' s certificate having a filing date before that of the application on which 
priority is claimed. 

Prior Foreign Application(s) Priority Not Claimed 
□ 

(Number) (Country) Day/Month/Year Filed 

□ 

(Nimiber) (Country) Day/Month/Year Filed 

Ciiereby claun the benefit under 35 U.S.C. § 120 or § 119(e) of any United States application(s), or § 365(c) of any PCT International application 
d&ignating the United States, listed below and, insofar as the subject matter of each of the claims of this application is not disclosed in the prior United 
sites or PCT International application(s) in the manner provided by the first paragraph of 35 U,S .C. § 112, 1 acknowledge the duty to disclose information 
!wfech is material to patentability as defmed in 37 CFR § 1.56 which became available between the filing date of the prior application and the national or 
g;T International filing date of this application. 



jC^pplication Serial No.) (Filing Date) (Status -- patented, pendmg, abandoned) 



tAppiication Serial No.) (Filing Date) (Stams - patented, pendmg, abandoned) 

Jllereby appoint the following attorneys and agent to prosecute this application and to transact all business in the Patent and Trademark Office connected 
.therewith; 

iSnes D- Halsey, Jr., 22,729; Harry John Staas, 22,010; David M. Pitcher, 25,908; John C. Garvey, 28,607; J. Randall Beckers, 30,358; William F. 
iferbert, 31,024; Richard A. Gollhofer, 31,106; MarkJ. Henry, 36,162; GeneM. Gamer II, 34,172; Michael D. Stem, 37,240; PaulL Kravetz, 35,230; 
%dd E. Marlette, 35,269; Norman L. Ourada, 41,235; Deborah S. Gladstein, 43,636; Jonathan H. Muskin, 43,824; Stephen Boughner, 45,317; John 
W Stowe, 32,863; C. Joan Gilsdorf, 43,635; Mehdi Sheikerz, 41,307; Edward V. Charbonneau, 35,428; James G. McEwen, 41,983; and William M. 
Schertler, 35,348 (agent) 

Address all correspondence to: STAAS & HALSEY LLP, 700 Eleventh Street, N.W., Suite 500, Washington, D.C. 20001 
Direct all telephone calls to: (202) 434-1500 - Facsimile No. (202) 434-1501 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and belief are believed to be 
true; and further that these statements were made with the knowledge that willful false statements and the like so made are punishable by fme or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false statements may jeopardize the validity of the 
• application or any patent issued thereon. 

Full name of sole or first inventoj; KeviyPeter P: 

Inventor's Signature )[_ 
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Residence 1344 Beaufoif Drive, Burlingti 
Post Office Address same as above 



Full name of second joint inventor, if any _ 



Second Inventor's Signature . ^^^^ . 



Residence Citizenship . 

Post Office Address „ 



□ Additional inventors are being named on separately numbered sheets attached hereto. 



United States Patent & Trademark Office 

Office of Initial Patent Examination - Scanning Division 




Applicaiion deficiencies were found during scanning; 
■1] Page! s) 01 ' were not present 

Mot scanning. (Document title) 



□ Page(s) of 



were not present 



, for scanning. (Document title) 



n Scanned copy is besi available. 



